Forwarding Internet Protocol Version 6 Link-Local Multicast to Support Roaming of Wireless Mobile Client Devices

ABSTRACT

Techniques are provided for a foreign controller to receive a handoff message including information for a multicast group that is used to forward network control information originating from an Internet Protocol version 6 (IPv 6 ) network router by a home wireless controller to one or more foreign wireless controllers for mobile client devices that were first associated with the home controller. The foreign controller joins a multicast group based on the information contained in the handoff message and establishes a communication path with a mobile client device. The foreign controller extracts network control information addressed to the mobile client device received from the home wireless controller via a multicast stream associated with the multicast group, and forwards the network control information to the mobile client device via the communication path.

TECHNICAL FIELD

The present disclosure relates to control message routing in a networkenvironment where wireless mobile client devices may roam from onewireless local area network device to another wireless local areanetwork device.

BACKGROUND

Internet Protocol version 6 (IPv6) is the next-generation Internetworking protocol version designated as the successor to IPv4. IPv4 isthe first implementation used in the Internet and is still widely used.IPv6 has a vastly larger address space than IPv4. This results from theuse of a 128-bit address, whereas IPv4 uses only 32 bits. This expansionprovides flexibility in allocating addresses and routing traffic andeliminates the need for network address translation (NAT), which gainedwidespread deployment as an effort to alleviate IPv4 address exhaustion.

IPv6 does not implement traditional IPv4 broadcast and does not use anyspecial broadcast address for transmitting a packet to all hosts on anattached physical link. IPv6 achieves a broadcast-like result by sendinga packet to a link-local multicast group address. IPv6 uses link-localmulticast to communicate application specific, management, or controlinformation to client devices on the link-local multicast network. Sincelink-local multicast is local to a particular wireless local areanetwork and wireless controller, link-local multicast packets are notforwarded to remote wireless controllers or networks. Applications suchas multicast Domain Name Service (mDNS) and Universal Plug and Play(UPnP) stop working after a roaming client stops receiving theirlink-local multicast control information.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a communication network environment inwhich wireless mobile client devices may roam from one wireless accesspoint to another and in which control messages are forwarded accordingto techniques described herein.

FIG. 2 is a block diagram for a controller that is configured to forwardcontrol messages according to techniques described herein.

FIG. 3A is a flow chart depicting a control message forwarding processperformed in a first wireless access point controller to forward IPv6link-local multicast control messages to individual wireless mobileclient devices that were initially associated with the first wirelessaccess point, but have roamed.

FIG. 3B is a flow chart depicting a control message receiving processperformed in a second wireless controller to forward IPv6 link-localmulticast control messages from the first wireless controller toindividual wireless mobile client devices served by the second wirelesscontroller.

FIG. 4 is an example of data in a multicast stream used to forward IPv6link-local multicast information according to techniques describedherein.

DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

Techniques are disclosed to establish a first communication path betweena first wireless controller and a mobile client device in a firstnetwork, where the first communication path is used to send networkcontrol information originating from an Internet Protocol version 6(IPv6) network router from the first wireless controller to the mobileclient device. Roaming of the mobile client device from the firstnetwork to a second network is detected by a second wireless controllerin the second network. A handoff message is transmitted from the firstwireless controller to the second wireless controller. The handoffmessage comprises information for a multicast group that is used toforward the network control information by the first wireless controllerto one or more secondary wireless controllers for mobile client devicesthat were first associated with the first wireless controller.

The handoff message is received at the second wireless controller. Thesecond wireless controller joins a Source Specific Multicast (SSM) groupbased on the information contained in the handoff message. A secondcommunication path is established between the second wireless controllerand the mobile client device. The second wireless controller extractsthe network control information addressed to the mobile client devicereceived from the first wireless controller via an SSM multicast stream.The network control information is forwarded to the mobile client devicevia the second communication path.

Example Embodiments

Reference is first made to FIG. 1 that shows a block diagram of anetworking environment to which the techniques described herein areapplicable. FIG. 1 generally depicts a configuration that is common inbridging a wired network with a wireless network. There is a firstnetwork router 10(1) on a first virtual local area network (VLAN), wherea VLAN is defined logically as a different IPv6 subnet. The firstnetwork router 10(1) communicates with a first controller 20(1). Thefirst network router 10(1) communicates, via a control and provisioningof wireless access point (CAPWAP) tunnel or other layer2/layer3 tunnel,with a first controller 20(1).

Similarly, there is a network router 10(2) that communicates with asecond controller 20(2) that is associated with a second VLAN. Thesecond controller 20(2) communicates with and controls APs 32(1)-32(Q),and these APs provide wireless connectivity with CDs 40(3) and 40(4),for example. Each of the controllers 20(1) and 20(2) may provide controlfunctionality for multiples sets of APs and for a plurality of differentVLANs. The controller 20(1) exchanges management or network controlinformation with controller 20(2) over Multicast Routing Protocol (MRP)network, e.g., Protocol Independent Multicast (PIM) network 15 using acontroller-to-controller SSM multicast tunnel 50 according to thetechniques described herein. Local distribution of the network controlinformation may be made by way Internet Group Management Protocolversion 3 (IGMPv3) networks associated with each VLAN.

Briefly, an SSM address is used by the forwarding controller to forwardnetwork control information that is normally sent by way of link-localmulticast to a receiving controller by way of an SSM tunnel, e.g.,controller-to-controller SSM multicast tunnel 50. The receivingcontroller subscribes to the associated SSM stream and a CD specificidentifier in the SSM stream delimits CD specific data by way oftechniques described herein. Examples and details will be described inthe text that follows.

In this example, the routers 10(1) and 10(2) are considered to be IPv6routers and in this regard routers 10(1) and 10(2) service the IPv6traffic to and from the CDs, e.g., CDs 40(1)-40(4), and also service thecontroller-to-controller exchange of network control information viacontroller-to-controller SSM multicast tunnel 50. With regard to theexchange of control information, the routers 10(1) and 10(2) may be IPv6or IPv4 routers. However, as shown in FIG. 1 the first and second VLANsare IPv6 VLANs in the IPv6 domain as indicated by the dashed ovalsaround the VLANs. Should the routers 10(1) and 10(2) be IPv4 routers,then separate IPv6 routers would be used to route CD traffic through thecontrollers. In other words, the controllers 20(1) and 20(2) may beconnected to a plurality of routers with at least one router that isIPv6-capable.

The CDs shown in FIG. 1 may be mobile and thus move between coverageareas of APs. Each VLAN has a different IPv6 subnet/prefix. When a CDfirst attaches (or in WLAN parlance “associates”) with any of thewireless APs controlled by one of the controllers 20(1) or 20(2), the CDwill be made part of that VLAN (IPv6 subnet) which that AP or anassociated switch is configured to serve. The CD then is said to belongto or is a part of that VLAN or subnet. As part of creating thisassociation between the CD and the VLAN, unique IPv6 addresses areassigned to the CD using the aggregate prefix block (subnet block)allocated to the VLAN. When the CD's state is removed, these addressesare released and recycled. The controller controlling that AP for thefirst point of attachment becomes the “home” controller for that CD.

Assuming for the sake of an example that CDs 40(1) and 40(2) first enterthe mobility or wireless network domain at one of the APs 30(1)-30(N),and then these CDs are assigned an IPv6 address with a subnet prefixthat corresponds to a subnet prefix assigned to the network router10(1). Specifically, the controller 20(1) allocates an IPv6 subnetprefix of network router 10(1) as the network prefix for CDs 40(1) and40(2). The controller at which the CD initially enters the mobilitydomain stores entry information for that CD comprising a media accesscontrol (MAC) address for the CD, an assigned IPv6 home network prefix,and a home controller ID (e.g., ID for controller 20(1)). Thus, the VLANfor CDs 40(1) and 40(2) is the first VLAN under control of thecontroller 20(1) and corresponding to network router 10(1). Once thisinitial VLAN assignment is made, the CDs 40(1) and 40(2) will always bepart of the first VLAN and all other controllers (and APs) will storedata indicating that association. A CD can obtain one or more IPv6network addresses from the prefix corresponding to its initial VLAN itdiscovers when entering the mobility domain, and can retain thoseaddresses even after moving anywhere within the mobility domain.Consequently, with respect to CDs 40(1) and 40(2), the second controller20(2) is referred to as a “foreign” controller because it controls APsthat are configured to serve CDs in other VLANs.

The first controller 20(1) communicates with and controls a plurality ofwireless LAN (WLAN) access points (APs) 30(1)-30(N) via CAPWAP or otherLayer2/Layer3 tunnels. The first controller 20(1) serves as a bridgebetween the wired network of which the network router 10(1) is a partand the wireless network served by the APs 30(1)-30(N). The APs30(1)-30(N) provide wireless connectivity with wireless client devices(CDs), an example of which are shown at reference numerals 40(1) and40(2).

The first controller 20(1) controls the APs 30(1)-30(N) which serve CDsthat belong to a particular subnet and thus may be said to belong to afirst VLAN insofar as they are associated with a unique IPv6 subnetserved by network router 10(1). Likewise, the second controller 20(2)controls the APs 32(1)-32(Q) which serve CDs that belong to a secondsubnet and thus belong to a second VLAN served by network router 10(2).The controllers 20(1) and 20(2) are, for example, wireless LANcontroller devices that are configured to provide a management point fora group of APs, and to route traffic between the wired and wirelessnetworks. An AP may be said to host a VLAN in that it serves CDs thatbelong to that VLAN. Multiple APs under control of the same controllermay host the same VLAN in that those multiple APs may serve CDs in thesame VLAN. When a CD roams from one AP to another AP, the CD may attachto an AP that is not responsible for hosting that CD's VLAN. In thisexample, CD 40(1) is shown roaming from a first VLAN to a second VLAN.

The home controller, i.e., the first controller 20(1), broadcastsnetwork control information that originates from network router 10(1) toCDs associated with APs under the home controller's control by way of anIPv6 link-local multicast group. When a CD roams from one WLAN toanother, e.g., when CD 40(1) roams from the first VLAN to the secondVLAN, the CD can no longer receive link-local multicast group traffic.It is of note that CDs that roam, e.g., CD 40(1), maintain theiroriginal IPv6 addresses from their first VLAN after roaming. There iscurrently no IPv6 mechanism for CD 40(1)'s home controller, e.g.,controller 20(1), to broadcast IPv6 link-local multicast traffic from anoriginating IPv6 router to CDs that have roamed, e.g., CD 40(1). Assuch, applications that require network control information such as UPnPor mDNSv6 cease to function after a CD has roamed.

The challenges of developing a scalable forwarding solution forlink-local multicast forwarding from one controller to multiple remotecontrollers include: 1) as the numbers of CDs, WLANs, and wirelesscontrollers increase, directly unicasting home link-local multicast fromone controller to another creates many one-to-one (or many-to-many)unicast relationships that becomes exponentially difficult to manage, 2)global multicasting of link-local multicast of multiple WLANs of acontroller to all other controllers is not scalable because that schemewould require a single multicast destination address per controller, andtherefore, requires a large number of IP multicast addresses and asophisticated destination address distribution system, and 3)multiplexing the link-local multicast of the multiple home link-localnetworks of a controller into a single multicast stream can requireexpensive de-multiplexing at the receiver.

According to the techniques described herein, link-local multicasttraffic can be sent to CD 40(1) using the controller-to-controller SSMtunnel 50 that is set up between controller 20(1) and controller 20(2).Link-local multicast data sent to CD 40(1) after CD 40(1) has roamed isshown by the dashed line from controller 20(1) to CD 40(1). Even thoughCD 40(1) maintains its original IPv6 address from first VLAN afterroaming to the second VLAN, the controllers 20(1) and 20(2) are able toprovide link-local multicast data to CD 40(1) as if it had not roamed.

There may be network switches between the APs and the controller for agiven WLAN and switches between controllers and network routers. It isto be further understood that the configuration shown in FIG. 1 is avery simple representation and that there are, in practice, many morecontrollers and VLANs in any given network environment. Furthermore, theterm “AP” or wireless access point device is meant to refer to anywireless device that provides wireless connectivity in a wirelessnetwork, and is not to be limited to, for example, WiFi™ (IEEE 802.11)APs. For example the techniques described herein are applicable to otherwireless networks, such as a WiMAX™ (IEEE 802.16) wireless network,where devices known as base stations in WiMAX parlance perform functionssimilar to that of an AP in an IEEE 802.11 wireless network Likewise,the term “controller” or “WLAN controller” is meant to refer to anycontrol apparatus that controls a wireless device that provides wirelessconnectivity in wireless network, and includes for example, a wirelessgateway device. A WiMAX wireless network is only one example of otherwireless networks to which these techniques are applicable. Thus, theconfiguration shown in FIG. 1 is only meant to be an example forpurposes of describing the techniques herein.

The controllers 20(1) and 20(2), via the aforementioned CAPWAP or otherlayer-2/layer-3 tunnels, communicate with each other in order to shareinformation as to the VLAN of each CD that has entered the mobilitydomain in the network. In addition, through these same tunnels, when aCD roams from a first AP to a second AP that is controlled by adifferent controller, the controller for the second AP to which it roamsshares information with the controller for the first AP. In this way, atany given time, controller 20(1) stores “mobility data” that comprisesinformation identifying all other controllers that controls APs to whichat least one CD has roamed from. The same applies to controller 20(2)for all CDs that belong to the second VLAN. Moreover, each controller20(1) and 20(2) stores information identifying each of the one or moreAPs that it controls.

Referring now to FIG. 2, a block diagram is shown that is meant torepresent an example of a block diagram for the controllers 20(1) and20(2), which are configured to perform the link-local multicastforwarding techniques described herein. There is a processor 22, anetwork interface unit 24 and a memory 26. The processor 22 is forexample, a microprocessor, a microcontroller, a digital signalprocessor, etc. The network interface unit 24 is a device that isconfigured to enable communications over a wired or wireless networkaccording to any of a variety of networking protocols.

The memory 26 is a tangible processor readable or computer readablestorage media (e.g., memory device) that stores or encoded withinstructions that, when executed by the processor 22, cause theprocessor 22 to perform functions described herein. The memory 26 maycomprise read only memory (ROM), random access memory (RAM), magneticdisk storage media devices, optical storage media devices, flash memorydevices, electrical, optical, or other physical/tangible memory storagedevices. The processor 22 is, for example, a microprocessor ormicrocontroller that executes instructions stored in memory 26. Thus, ingeneral, the memory 26 may comprise one or more computer readablestorage media (e.g., a memory device) encoded with software comprisingcomputer executable instructions and when the software is executed (bythe processor 22) it is operable to perform the operations describedherein. For example, the memory 26 is encoded with instructions for amobility agent 28 and for link-local multicast forwarding for roamedmobile device process logic 300. The mobility agent 28 manages mobilityinformation for the controller whether acting as a home controller or aforeign controller. The process logic 300 is described hereinafter inconnection with FIGS. 3A, 3B, and 4.

While FIG. 2 shows a processing environment comprising a data processor22 that executes software stored in memory 26, an alternative processingenvironment is a fixed data processing element, such as an applicationspecific integrated circuit (ASIC) that is configured, through fixedhardware logic, to perform the functions of the logic 300. Yet anotherpossible data processing environment is one involving one or more fieldprogrammable logic devices, or a combination of fixed processingelements and programmable logic devices.

The memory 26 also stores the aforementioned mobility data shown atreference numeral 29. Again, the mobility data 29 comprises dataconcerning the home VLAN for CDs and current points of attachment of CDs(i.e., IDs for foreign controllers where a CD is currently attached). Inaddition, the memory 26 also stores AP IDs for all APs under itscontrol. Any of the devices, e.g., APs, CDs, or routers, shown in thefigures may use some or all of the components as those described for acontroller in connection with FIG. 2. The wireless devices may employ anetwork interface unit with wireless capability.

Turning to FIGS. 3A and 3B, a flow chart is described for the link-localmulticast forwarding for roamed mobile device process logic 300. FIG. 3Adepicts elements for process 300 with respect to a home controller,e.g., controller 20(1), while FIG. 3B depicts elements for process 300with respect to a foreign controller, e.g., controller 20(2), from theperspective of a particular CD, e.g., CD 40(1). At 310, a firstcommunication path is established between a first wireless controllerand a mobile client device in a first network, wherein the firstcommunication path is used to send control or management informationfrom the first wireless controller to the mobile client device. Thiscommunication path uses link-local multicast techniques to broadcast thenetwork control information originating from an IPv6 network router. At320, roaming of the mobile client device from the first network to asecond network is detected by a second wireless controller in the secondnetwork. At 330, a handoff message is transmitted from the firstwireless controller to the second wireless controller. The handoffmessage comprises information for a multicast group that is used toforward network control information by the first wireless controller toone or more secondary wireless controllers for mobile client devicesthat were first associated with the first controller.

The description that follows uses standard IGMP notation (S, G), where Sis the multicast stream source IPv6 address and G is the multicast groupIPv6 address. Any upper layer protocol module that has joined orsubscribed to (*, G) will receive the G addressed datagrams, i.e., each(*, G) socket receives the stream, where * indicates a wildcard addresswhich is considered an SSM address when used with the techniquesdescribed herein.

An IP SSM address is allocated to the forwarding controller forforwarding the IPv6 link-local multicast for the first communicationpath source address for the home controllers. For ease of explanation,the mobility agent (MA), e.g. mobility agent 28, associated with thefirst controller is referred to herein as MA1, or as the controller/MAcombination as controller MA1, while the mobility agent associated withthe second controller is referred to herein as MA2 or controller MA2.When a CD roams from a network controller, e.g., controller 20(1), MA1to foreign controller MA2, controller MA2 will join the SSM stream(S_(MA1), G). In this manner, only foreign controllers interested in MA1link-local multicast will subscribe to the traffic from MA1.

The mobility handoff message from controller MA1 to MA2 includesinformation that may be used to uniquely identify network controlinformation for the CD. For example, the mobility handoff message mayinclude information comprising a VLAN identifier (ID), a unique networkID (e.g., a bridge domain ID), and a link-local multicast group address(G)). Based on the information, both MA1 and MA2 derive a single andunique global multicast group identifier (MGID) tag denoted as M. TheMGID is generated using an algorithm that is known to controllersconfigured with process logic 300. The MGID is stored along with theassociated CD for which the handoff message was received. The MGID isnot generated based on CD information. Accordingly, the same MGID may beused for plural CDs that have roamed from the same controller and VLANto different VLANs associated with different foreign controllers.

The bridge domain ID is included in the handoff message to distinguishsource or home VLANs from foreign VLANs. VLAN identifiers may berandomly selected, e.g., VLAN 6 or VLAN 100, or arbitrarily assigned.For example, the first VLAN and the second VLAN identified in FIG. 1 maycoincidentally have the same VLAN ID, e.g., VLAN 1. In such cases theMGID can not be made unique unless the bridge identifier for acontroller, e.g., controller 20(1), or some other unique piece ofinformation is included in the handoff message.

The MGID is attached to packets of the multicast stream, e.g., into SSMstream (S_(MA1), G). The MGID is used to distinguish between themultiple VLANs or subnets that the controller is managing. As a result,the controller can multiplex network control information from multipleIPv6 networks into a single SSM stream that any foreign controller cansubscribe to. The home controller, e.g., MA1, tunnels link-localmulticast packets to an SSM tunnel, e.g., (S_(MA1), G) viacontroller-to-controller SSM tunnel 50, and may embed the MGID M in thepayload header. An example SSM stream is illustrated in FIG. 4. FIG. 4depicts an SSM stream 400 that is generated by a single controller MA,e.g., MA1. Stream 400 comprises a plurality of MGIDs labeled from MGID 1to MGID Z. Following the MGID is the associated link-local multicastgroup (LLMG) data, e.g., LLMG1, LLMG2 . . . LLMG Z. The data need not bearranged in order, i.e., MGIDs and associated data may be transmitted inany order as the data become available.

The global MGID may be sized in bytes, e.g., 1-8 bytes, to accommodateas many MGIDs per switch/VLAN/link-local multicast groups that areanticipated. In one example, 12 bits of the MGID may be used to supportapproximately 4000 VLANs on a given switching network. Seven bits of theMGID can support 128 bridge ID/domains and 8 bits of the MGID canidentify current and future IPv6 link-local applications. Currentlythere are about 30 known link-local multicast applications. When alink-local multicast is used, the multicast destination address mayindicate a specific application. For example, the addressFF02:0:0:0:0:0:0:F is associated with UPnP and the addressFF02:0:0:0:0:0:0:FB is associated with multicast Domain Name ServicemDNS. This associated application address can be converted to a bitfield within the MGID.

The MGIDs may be stored in an MGID table on the controller (or at aconvenient storage location) for any active CDs that are associated toan AP being serviced by that controller. The MGID will be used by theservicing controller, e.g., controller MA2, to identify the link-localmulticast payload in the SSM stream as described above. Once thelink-local multicast payload is identified, MA2 by way of an AP convertsthe multicast stream to unicast for direct forwarding of the link-localinformation to individual roaming CDs.

In some network environments hardware assisted forwarding is employed,e.g., ASICs may act as forwarding engines that perform packet addressingand rewrites in hardware. In these cases, the processors, e.g.,processor 22, of MAs loaded on devices that employ hardware forwardingengines, plumb down the MGID to the hardware level. Accordingly,hardware fast-forwarding and receiving may be used by home and foreigncontrollers, whether the controllers are using electrical or opticalphysical layers. Payloads for different MGIDs may also be sent in(S_(MA1), G) and tagged with different User Datagram Protocol (UDP)ports for fast filtering at the destination.

The process continues with respect to a foreign controller in FIG. 3B.At 340, the handoff message is received at the second wirelesscontroller. At 350, the second wireless controller joins a multicastgroup based on the information contained in the handoff message. Forexample, the foreign controller, e.g., MA2, receives the link-localtraffic by subscribing to the corresponding SSM stream, e.g., (S_(MA1),G). The information contained in the handoff message may be obtainedfrom the mobile client device. In other words, S_(MA1) may be receivedfrom either the first controller or the mobile client device, while Gmay be known to the network, i.e., pre-configured, or G may beestablished at run-time. Duplicate subscriptions for the same globalMGID of the same (VLAN, bridge domain ID, link-local multicast group)can be eliminated by the home controller, e.g., MA1, by cross-checkingthe local MGID table, before sending duplicate data in (S_(MA1), G). At360, a second communication path is established between the secondwireless controller and the mobile client device.

Although the term “path” has been used herein with regard to the firstand second communication paths from the first and second controllers tothe mobile client device, it is to be understood that their may be manyphysical communications links from the controller to the mobile clientdevice. For example, the path may comprise one or more wired or wirelessphysical links from the controller to the AP, e.g., MA1 to AP, and awireless physical link from the AP to the mobile client device. Hence,the term “path” is meant to encompass all of the links that are requiredto establish the requisite communications.

At 370, the second wireless controller extracts the network controlinformation for the mobile client device received from the firstwireless controller via a SSM multicast stream. When hardwareacceleration is used, the MA2 forwarding engine identifies thelink-local multicast payload by filtering on the MGID in the packetheader, swaps the payload packet IP header with MA2 and MA2/APaddresses, and sends the payload to the AP. At 380, the network controlinformation is forwarded to the mobile client device via the secondcommunication path. The AP of the foreign controller, e.g., MA2, looksat the global MGID and client list mapping, and then converts the steamin order to unicast the link-local multicast information to acorresponding roaming client as described above.

In summary, techniques are described herein to establish a firstcommunication path between a first wireless controller and a mobileclient device in a first network, where the first communication path isused to send network control information from the first wirelesscontroller to the mobile client device. Roaming of the mobile clientdevice from the first network to a second network is detected by asecond wireless controller in the second network. A handoff message istransmitted from the first wireless controller to the second wirelesscontroller. The handoff message comprises information for a multicastgroup that is used to forward network control information by the firstwireless controller to one or more secondary wireless controllers formobile client devices that were first associated with the firstcontroller.

The handoff message is received at the second wireless controller. Thesecond wireless controller joins a multicast group based on theinformation contained in the handoff message. A second communicationpath is established between the second wireless controller and themobile client device. The second wireless controller extracts thenetwork control information addressed to the mobile client devicereceived from the first wireless controller via the SSM multicaststream. The network control information is forwarded to the mobileclient device via the second communication path.

The handoff message may contain multicast group information comprising avirtual local area network identifier, a unique identifier for the firstwireless controller or bridge domain identifier used by the firstwireless controller, and a link-local multicast group address. Amulticast group identifier is generated at the first and second wirelesscontrollers that configured to identify the network control informationfor the mobile client device within the multicast stream based on thevirtual local area network identifier, the bridge domain identifier, andthe link-local multicast group address using a predetermined algorithm.The multicast group identifier is stored at each of the first and secondwireless controllers. The first network may be considered a home networkthat was once used by the mobile client device and managed by the firstcontroller which may be considered the home controller. Accordingly, thebridge domain identifier may be considered a bridge domain identifierused by the home controller.

The multicast group identifier is inserted into payload header of theSSM multicast stream by the first wireless controller in order for thesecond wireless controller to identify the network control informationfor the mobile client device within the multicast stream. The networkcontrol information is extracted based on the multicast group identifierby the second wireless controller.

The multicast group identifier may be associated with a correspondingidentifier, e.g., a UDP port, for filtering at the destination. Thesecond wireless controller converts a packet address in the multicaststream to an address associated with the second wireless controller anda wireless access point address based on the multicast group identifier.The wireless access point further converts the multicast stream to aunicast stream for transmission to the mobile client device.

The second wireless controller joins the SSM multicast group of thesource address of the first wireless controller and a pre-defined (orconfigurable) SSM destination multicast group address. The unicast IPaddress of the first wireless controller comprises an SSM source addressand an IP multicast group address comprises the SSM destination groupaddress. A SSM tunnel is created from the first wireless controller tothe second wireless controller in order to send the multicast stream.

The SSM address is used to forward IPv6 link-local multicast from hometo foreign controllers and networks. The SSM destination address is aglobal IP multicast address, and the source addresses are the addressesof the home controllers. Link-local multicast for a roamed wirelessclient is added to the multicast stream on-demand when home controlleris informed of the roaming event. The foreign controller can obtain thehome controller's address from the wireless client or via mobilityhandoff message exchange. The home controller can put link-localmulticast of different local networks into different UDP streams forseamless filtering at remote foreign controllers. The foreign controllerand AP of attachment perform any address conversions to unicast thelink-local multicast information from the home network to the roamingCD.

There are no techniques heretofore known for extending IPv6 link-localmulticast beyond wireless local area networks (WLANs) to providemobility support for mobile client devices that have roamed to anotherWLAN. The techniques described herein allow an IPv6 wireless mobileclient device to be part of an enterprise virtual local area network(VLAN) and to change its point of attachment to a different wirelessaccess point and still receive information from its home controller'sIPv6 link-local multicast group.

The techniques described herein provide several advantages. For example,using SSM to distribute IPv6 link-local multicast only requires a singleglobal multicast address for forwarding the link-local information. TheIP address of the controller is used as the SSM source address.Accordingly, this scheme is relatively easy to manage and is scalablewhen compared to any alternatives. It eliminates the drawbacks ofdesigns that require direct unicasting or multiple multicast addresses.The use of multiple UDP streams within a single SSM stream allows aremote controller to efficiently filter out link-local data that isintended for other foreign controllers.

Although the techniques are illustrated and described herein as embodiedin one or more specific examples, it is nevertheless not intended to belimited to the details shown, since various modifications and structuralchanges may be made therein without departing from the scope of the andrange of equivalents of the claims.

1. A method comprising: receiving a handoff message at a second wirelesscontroller from a first wireless controller, the handoff messagecomprising information for a multicast group that is used to forwardnetwork control information originating from an Internet Protocolversion 6 (IPv6) network router, wherein the network control informationis intended for a mobile client device that was first associated withthe first wireless controller; joining, by the second wirelesscontroller, a multicast group based on the information contained in thehandoff message; establishing a communication path between the secondwireless controller and the mobile client device; extracting by thesecond wireless controller network control information for the mobileclient device received from the first wireless controller via amulticast stream associated with the multicast group; and forwarding thenetwork control information to the mobile client device via thecommunication path.
 2. The method of claim 1, wherein receivingcomprises receiving the handoff message with multicast group informationcomprising information configured to identify the network controlinformation in the multicast stream.
 3. The method of claim 1, whereinreceiving comprises receiving the handoff message with multicast groupinformation comprising a virtual local area network identifier, anetwork identifier that uniquely identifies a network associated withthe first network controller, and a link-local multicast group address,and further comprising generating at the second wireless controller amulticast group identifier configured to identify the network controlinformation for the mobile client device within the multicast streambased on the virtual local area network identifier, the networkidentifier, and the link-local multicast group address.
 4. The method ofclaim 3, further comprising storing the multicast group identifier atone or more of the second wireless controller and a wireless accesspoint serving the mobile client device.
 5. The method of claim 3,wherein the multicast stream comprises the multicast group identifier inorder for the second wireless controller to identify the network controlinformation for the mobile client device within the multicast stream;and wherein extracting comprises extracting the network controlinformation based on the multicast group identifier.
 6. The method ofclaim 3, further comprising associating the multicast group identifierwith a corresponding User Datagram Port identifier.
 7. The method ofclaim 3, further comprising at the second wireless controller convertinga packet address in the multicast stream to an address associated withthe second wireless controller and a wireless access point address basedon the multicast group identifier.
 8. The method of claim 7, furthercomprising at the wireless access point converting the multicast streamto a unicast stream for transmission to the mobile client device.
 9. Themethod of claim 1, wherein joining comprises joining the multicast groupcomprising an address of the first wireless controller and a knownmulticast group address.
 10. The method of claim 1, wherein receivingcomprises receiving the handoff message from the mobile client device.11. The method of claim 1, further comprising creating a Source SpecificMulticast (SSM) tunnel from the first wireless controller to the secondwireless controller in order to send the multicast stream.
 12. Anapparatus comprising: a network interface unit configured to send andreceive messages over a wired network; a processor configured to:receive, via the network interface unit, a handoff message comprisinginformation for a multicast group that is used to forward networkcontrol information originating from an Internet Protocol version 6(IPv6) network router via a home wireless controller to one or moreforeign wireless controllers for mobile client devices that were firstassociated with the home controller; join a multicast group based on theinformation contained in the handoff message; establish a communicationpath with a mobile client device; extract network control informationfor the mobile client device received from the home wireless controllervia a multicast stream associated with the multicast group; and forward,via the network interface unit, the network control information to themobile client device via the communication path.
 13. The apparatus ofclaim 12, wherein the processor is configured to join the multicastgroup comprising an address of the home wireless controller and a knownmulticast group address.
 14. The apparatus of claim 12, wherein theprocessor is configured to receive the handoff message from the mobileclient device.
 15. The apparatus of claim 12, wherein the processor isconfigured to receive the handoff message with multicast groupinformation comprising a virtual local area network identifier, anetwork identifier that uniquely identifies the home controller, and alink-local multicast group address.
 16. The apparatus of claim 15,wherein the processor is further configured to generate a multicastgroup identifier configured to identify the network control informationfor the mobile client device within the multicast stream based on thevirtual local area network identifier, the network identifier, and thelink-local multicast group address.
 17. The apparatus of claim 16,wherein the processor is further configured to identify the networkcontrol information for the mobile client device within the multicaststream and to extract the network control information based on themulticast group identifier.
 18. The apparatus of claim 16, wherein theprocessor is further configured to convert a packet address in themulticast stream to an address associated with the apparatus and awireless access point address based on the multicast group identifier.19. A system comprising the apparatus of claim 18 and the wirelessaccess point, wherein the wireless access point is configured to convertthe multicast stream to a unicast stream for transmission to the mobileclient device.
 20. One or more computer readable storage media encodedwith software instructions that when executed are operable to: receive ahandoff message comprising information for a multicast group that isused to forward network control information originating from an InternetProtocol version 6 (IPv6) network router via a home wireless controllerto one or more foreign wireless controllers for mobile client devicesthat were first associated with the home controller; join a multicastgroup based on the information contained in the handoff message;establish a communication path with a mobile client device; extractnetwork control information for the mobile client device received fromthe home wireless controller via a multicast stream associated with themulticast group; and forward the network control information to themobile client device via the communication path.
 21. The computerreadable storage media of claim 20, wherein the instructions that areoperable to join comprise instructions operable to join the multicastgroup comprising an address of the home wireless controller and a knownmulticast group address.
 22. The computer readable storage media ofclaim 21, wherein the instructions that are operable to receive compriseinstructions operable to receive the handoff message from the mobileclient device.
 23. The computer readable storage media of claim 22,wherein the instructions that are operable to receive compriseinstructions operable to receive the handoff message with multicastgroup information comprising a virtual local area network identifier, anetwork identifier that uniquely identifies the home controller, and alink-local multicast group address, and further comprising instructionsthat when executed are operable to: generate a multicast groupidentifier configured to identify the network control information forthe mobile client device within the multicast stream based on thevirtual local area network identifier, the network identifier, and thelink-local multicast group address using a predetermined algorithm; andidentify the network control information for the mobile client devicewithin the multicast stream; and wherein the instructions that areoperable to extract comprise instructions operable to extract thenetwork control information based on the multicast group identifier. 24.A method comprising: establishing a communication path between awireless controller and a mobile client device in a first network,wherein the communication path is used to send network controlinformation originating from an Internet Protocol version 6 (IPv6)network router from the wireless controller to the mobile client device;detecting roaming of the mobile client device from the first network toa second network; and transmitting a handoff message from the wirelesscontroller to the second network, the handoff message comprisinginformation for a multicast group that is used to forward networkcontrol information by the wireless controller to one or more secondarywireless controllers for mobile client devices that were firstassociated with the wireless controller.
 25. The method of claim 24,wherein transmitting comprises transmitting the handoff message withmulticast group information comprising a virtual local area networkidentifier, a network identifier that uniquely identifies the firstnetwork, and a link-local multicast group address.
 26. The method ofclaim 25, further comprising generating at the wireless controller amulticast group identifier configured to identify the network controlinformation for the mobile client device within the multicast streambased on the virtual local area network identifier, the networkidentifier, and the link-local multicast group address.
 27. The methodof claim 26, further comprising storing the multicast group identifierat the wireless controller.
 28. The method of claim 26, furthercomprising inserting the multicast group identifier into the multicaststream by the wireless controller in order for the second network toidentify the network control information for the mobile client devicewithin the multicast stream.
 29. The method of claim 26, whereininserting comprises inserting the multicast group identifier into apayload header.
 30. The method of claim 26, further comprisingassociating the multicast group identifier with a corresponding UserDatagram Port identifier.